It is not unusual for distributed teams to work together virtually in a team space. Typical collaborative activities involve the development of a software asset, as well as consumption of the asset in a way that is cost effective. There are many social networking software programs and other tools that allow an asset provider and asset consumers to connect or collaborate through computer technology. Often, conventional collaboration takes place in more than one team area of the same project corresponding to the asset that is produced. For example, a project may use team room, a wiki, and a blog (or some other collaboration space) to reach out to the appropriate user community. Information about a software asset can be duplicated in all these places, and users may need to monitor all applicable communication channels to ensure the integrity of information published. The benefits of social networking tools sometimes also bring the challenges for users to identify which team areas are indeed worth close monitoring and which team areas only warrant casual engagement.
A social networking service is often a web based internet/intranet collaboration/information sharing service. The shared information is often accessible to the public. Additionally, other people with similar interests can view the information by category or tags of a folksonomy. Most conventional social networking services have algorithms to implement the concept of inference from the tag by examining the clustering of particular tags and, hence, finding relationship between one another. An important element in most of these services is the concept of a person's community, which means providing a way to rank query results based on the person's social network, which includes direct associates and more distant associates separated by degrees. Most of these conventional social networking services provide aggregate news feeds of places, filtered by tags, that a person's social network finds interesting. Many conventional social networking services also provide ways to attach comments and/or ratings to items indexed by the tags. It should be noted that the tags themselves also have a community, which includes the collection of people who use a tag to describe an object. Similarly, the objects also have a community, which includes the people who tag a particular object.
Given the successes of the open source software (OSS) approach to software development, many firms have started to apply the best practices of OSS to traditional closed-source development. An open collaborative development approach enables a single firm to leverage skills of all of its employees to benefit the entire organization, or at least a relatively large portion of the organization. With an open collaborative environment for development teams, harvesting software assets for reuse (e.g., in derivative applications) is facilitated and often encouraged.
Role based access control (RBAC) is a widely used approach in computer security systems to restrict collaborative access to only authorized users. Roles are typically associated with job functions in an organization. Specific roles are assigned permissions to perform specific operations. In general, specifying access rights based on roles is a good way to manage system security in the traditional software development world. However, while RBAC ensures that only authorized users are allowed to access certain types of information in a virtual collaboration community, the traditional RBAC approach is difficult to manage. Additionally, the traditional RBAC approach relies on constant oversight to determine and set up access rights for each individual. Also, access rights based solely on an individual's role may not be very effective since useful input is often desired from people who are not granted access rights to the collaborative environment. Additionally, in an open collaborative environment, individual RBAC is usually not sufficient because the potential community associated with the collaborative development asset is often far more comprehensive than including just a few people.
Furthermore, a person very often has more than one role for various projects. A predefined set of roles is usually not sufficient to satisfy all possible operational control. Frequently, a new custom role needs to be defined based on a particular scenario or else work cannot be performed. The conventional RBAC system also does not have the flexibility and automation to effectively manage a transition when a member of the team leaves a job, which entails administrative functions to remove that person's access. Additionally, removing one person's rights to access information due to a job change may end up locking out other related users from continuing to access the collaborative information.